Python 🐍 Work With Data

Рубрика "бла бла бла"

K8S vs Docker

Что может случиться, если в компании принимается решение об единообразной платформе развертывании контейнерных приложений? Например, в компании на высшем уровне договорились развертывать все контейнерные приложения для всех подразделений только на kubernetes. В таком случае будьте готовы, что это решение повлияет на развитии внутренних сервисов компании негативным образом.

Почему? Мощности подразделения DevOps могут быть ограничены, а работать с K8S могут быть подготовлены не все сотрудники. Призыв "А ну-ка изучите kubernetes" у многих может вызывать отторжение, хотя бы потому, что в свободное от работы время учить не хочется дополнительный инструмент, а в рабочее время - аврал и надо бежать делать другие задачи. Лично у меня еще срабатывает желание подтянуть Docker, а не идти еще учить k8s, который еще и сложнее на порядок.

Лучшим на мой взгляд решением является принятие единой технологической платформы только для критически важной инфраструктуры (в т.ч. сервисов, приносящих деньги). А для других подразделений можно предоставить выбор k8s или docker. При этом тем, кто выбрал docker оказывать необходимую поддержку (возможно даже нанять отдельного devops инженера с хорошими знаниями docker).

Такое решение поспособствует развитию локальных экспертиз отдельных команд, плюс развитие внутренних продуктов компании только ускорится. Не каждый сотрудник, изучив Docker готов пойти изучать еще и kubernetes.

---

Как это может повлиять на отдел аналитики? Например, сейчас я бы хотел развернуть в компании Apache Airflow, Apache NiFi и DataHub Project, но все это придется поднимать на kubernetes. Дополнительным условием является поднятие сразу двух сред prod и stage. Т.к. datahub еще состоит из множества сервисов, то связываться с ним devops не захотят. Какой результат? Правильно - никакой. Фактически внутри ИТ приняты договоренности, которые препятствуют развитию инструментария для работы с данными.

Да, можно выпросить Linux машину и все поставить самостоятельно сбоку. Но тогда возникает ситуация, при которой вроде договорились использовать k8s, а все равно сбоку отпочковываются сервисы на Docker. Плюс машины Linux админят разработчики, что не безопасно.

---

Резюмируя, хочу сказать следующее: прежде чем вводить ограничения внутри компании, подумайте стоит ли их распространять повсеместно. В ином случае наймите достаточное количество DevOps инженеров, которые бы делали бы все необходимые работы по k8s.

www.tg-me.com/no/Python Work With Data/com.python_powerbi/630

616 viewsedited  Jun 28, 2022 at 06:43

Рубрика "бла бла бла"

K8S vs Docker

Что может случиться, если в компании принимается решение об единообразной платформе развертывании контейнерных приложений? Например, в компании на высшем уровне договорились развертывать все контейнерные приложения для всех подразделений только на kubernetes. В таком случае будьте готовы, что это решение повлияет на развитии внутренних сервисов компании негативным образом.

Почему? Мощности подразделения DevOps могут быть ограничены, а работать с K8S могут быть подготовлены не все сотрудники. Призыв "А ну-ка изучите kubernetes" у многих может вызывать отторжение, хотя бы потому, что в свободное от работы время учить не хочется дополнительный инструмент, а в рабочее время - аврал и надо бежать делать другие задачи. Лично у меня еще срабатывает желание подтянуть Docker, а не идти еще учить k8s, который еще и сложнее на порядок.

Лучшим на мой взгляд решением является принятие единой технологической платформы только для критически важной инфраструктуры (в т.ч. сервисов, приносящих деньги). А для других подразделений можно предоставить выбор k8s или docker. При этом тем, кто выбрал docker оказывать необходимую поддержку (возможно даже нанять отдельного devops инженера с хорошими знаниями docker).

Такое решение поспособствует развитию локальных экспертиз отдельных команд, плюс развитие внутренних продуктов компании только ускорится. Не каждый сотрудник, изучив Docker готов пойти изучать еще и kubernetes.

---

Как это может повлиять на отдел аналитики? Например, сейчас я бы хотел развернуть в компании Apache Airflow, Apache NiFi и DataHub Project, но все это придется поднимать на kubernetes. Дополнительным условием является поднятие сразу двух сред prod и stage. Т.к. datahub еще состоит из множества сервисов, то связываться с ним devops не захотят. Какой результат? Правильно - никакой. Фактически внутри ИТ приняты договоренности, которые препятствуют развитию инструментария для работы с данными.

Да, можно выпросить Linux машину и все поставить самостоятельно сбоку. Но тогда возникает ситуация, при которой вроде договорились использовать k8s, а все равно сбоку отпочковываются сервисы на Docker. Плюс машины Linux админят разработчики, что не безопасно.

---

Резюмируя, хочу сказать следующее: прежде чем вводить ограничения внутри компании, подумайте стоит ли их распространять повсеместно. В ином случае наймите достаточное количество DevOps инженеров, которые бы делали бы все необходимые работы по k8s.

BY Python 🐍 Work With Data